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(54) Generating service detail records 

(57) Generalised service detail records are created 
for a telephony service carried over a packet data net- 
work by monitoring packet network service data, signal- 



ling data and quality of service data, and combining 
these data to produce the required service detail 
records. 
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Description 

Technical Field 

[0001] This invention relates to methods and appara- 
tus for generating service detail records, and to moni- 
toring systems for collecting data for these records from 
a network- such as a packet data network, which is used 
for example to carry multimedia telephony services as 
described in the International Telecommunication Un- 
ion's recommendation H .323 or the Internet Engineering 
Task Force's multimedia data and control architecture 
including the Session Initiation Protocol (SIP). These 
and similar standards define a set of protocols for es- 
tablishing sessions or calls which may include one or 
more users and one or more servers, communicating 
via one or more multimedia channels. 

Background 



and gatekeepers. 

[0005] According to a further aspect of this invention . 
there is provided a method of generating generalised 
service detail records for communications carried over 
5 a packet network, comprising the steps of: 

- acquiring packet network service data for the pack- 
ets carrying the communications service: 

- acquiring signalling data regarding at least one of 
to call control, registration, admissions, bandwidth 

management, call status, address translation and 
intelligent network services: 

- acquiring quality of service data for the service 
transmission level: and 

75 - combining said service data, said signalling data 
and said quality of service data to generate gener- 
alised service detail records. 



[0002] The provision of multimedia communications 
services over a packet data network (PDN) which may 
not provide quality of service guarantees has recently 
generated a great deal of interest due to the success of 
networks based on the internet protocols (TCP/IP). Net- 
work operators are currently triating multimedia commu- 
nications services over a variety of packet data networks 
such as Internet Protocol (IP), Frame Relay (FR) and 
Asynchronous Transfer Mode (ATM). A major problem 
is to generate service detail records (generalised call 
data records), in real-time or batch-mode, which meas- 
ure the service usage of individual users and the service 
quality that was actually experienced by the user. 



Disclosure of Invention 



[0003] According to one aspect of this invention there 
is provided a method of generating generalised service 
detail records for communications (such as telephony) 
carried over a packet network, comprising the steps of: *o 

- acquiring packet network service data from packets 
carrying the communications: 

- acquiring signalling data from a signalling protocol 
to identify at least one of addressing, configuration, is 
status and timing information for endpoints, gate- 
keepers and connections involved in a call: and 

- combining said packet service data and said signal- 
ling data to generate service detail records. 

so 

[0004] According to another aspect of this invention 
there is provided a method of discovering the network 
configuration of the endpoints, gatekeepers and their re- 
lationships, for a communications service (such as te- 
lephony) carried by a PDN, by using a passive monitor- ss 
ing system to capture the signalling messages involved 
in the configuration and negotiation of relationships, ad- 
dressing and resource allocation, between endpoints 



[0006] According to another aspect of this invention 
20 there is provided a method of monitoring a packet data 
sub-network (e.g. ethernet segment) or link (e.g. a T3 
link carrying IP over a Point-to-Point Protocol - PPP). 
comprising the steps of: monitoring at a first location sig- 
nalling messages to detect the existence of a call: and 
monitoring at multiple other locations to identify some 
or all packets associated with the call (in H.323, the Call 
ID can be used to identify all packets associated with a 
given call). The captured packets may include both sig- 
nalling data and data from multimedia streams associ- 
ated with the call. It may be required for wire-tap appli- 
cations, for example, to use the signalling data to identify 
calls of interest, and then capture the entire multimedia 
stream. It may be necessary to buffer captured packets' 
at each location to ensure that all packets associated 
35 with the call could be captured. 

[0007] In addition, the packets associated with a con- 
ference call can be correlated together to form a service 
record for a conference call. This can be achieved by 
capturing all packets with the same conference ID in H. 
323, for example. 

[0008] In some cases it may be desirable to monitor 
additional signalling messages, e.g. Signalling System 
No.7 (SS7) protocol messages or Integrated Services 
Digital Network (ISDN) messages, on signalling links in 
a switched circuit network (such as the public switched 
telephone network - PSTN) coupled to said packet data 
network, or Media Gateway Control protocol messages 
(for example MGCP or SGCP) which are used to control 
the gateway connection between the SCN and the PDN, 
to derive additional monitoring data, and correlate those 
additional monitoring data with at least some of first 
monitoring data. These can be correlated to the original 
call by using characteristics such as calling or called par- 
ty numbers to identify the call. 
[0009] Thus the invention can involve monitoring the 
control channels used for initiation, modification and ter- 
mination of multimedia sessions, and may include the 
monitoring of the multimedia channels themselves, to 
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ing call signalling messages: 
Figure 16 is a flow diagram of a process for monitor- 
ing control channels: and 
Figure 17 is a flow diagram of a process for monitor- 
5 ing call signalling channels having dy- 

namic TSAP identifiers. 



provide a service detail record for a session. 
[0010] The invention enables a network operator to 
generate service detail records on a pure PDN. or on a 
hybrid network of interconnected PDNs and switched 
circuit networks (SCNs). There is alsodescribed a meth- 
od for automatically discovering the network configura- 
tion information, including addressing and identifying 
the relationships between gatekeepers and endpoints. 

Brief Description of Drawings 

[0011] Methods and apparatus in accordance with 
this invention for generating telephone service detail 
records will now be described, by way of example, with 
reference to the accompanying drawings, in which: 

Figure 1 shows a distributed monitoring system for 
a PDN carrying multimedia voice servic- 
es: 

Figure 2 shows examples of extensions of this ar- 
chitecture to correlate data from the PDN 
with signalling data from the SCN: 

Figure 3 shows the sequence of message types 
which can be captured to construct a serv- 
ice detail record: 

Figure 4 shows an example of the structure of a 
service record that could be constructed 
from the data collected by the monitoring 
system; 

Figure 5 is a flow diagram of a process for monitor- 
ing signalling messages related to gate- 
keeper auto-discovery: 

Figure 6 is a flow diagram of a process for extract- 
ing data from gatekeeper auto-discovery 
messages; 

Figure 7 shows the relationship between the proc- 
esses of Figures 5 and 6: 

Figure 8 illustrates a failure mode which can affect 
the gatekeeper auto-discovery proce- 
dure: 

Figure 9 is a flow diagram of a process for monitor- 
ing signalling messages related to regis- 
tration of endpoints with gatekeepers; 

Figure 10 is a flow diagram of a process for extract- 
ing data from endpoint registration mes- 
sages; 

Figure 11 is a flow diagram of a process for extract- 
ing data from endpoint unregistration 
messages: 

Figure 12 illustrates potentially anomalous registra- 
tion of endpoints with a gatekeeper in a 
different sub-net: 

Figure 1 3 illustrates potentially anomalous load im- 
balance between two gatekeepers in a 
sub-net: 

Figure 14 is a flow diagram of a process for monitor- 
ing call signalling channels: 
Figure 15 is a flow diagram of a process for monitor- 



Best Mode for Carrying Out the Invention. & Industrial 
Applicability 

10 

[0012] The distributed monitoring system shown in 
the drawings has the capability to collect data from a 
combined PDN and SCN carrying multimedia services, 
correlate these data in real-time, and provide a real-time 

is view of services on the network. These data can be used 
for applications such as troubleshooting, surveillance, 
security, network planning, provision of accounting in- 
formation to customers, fraud detection, billing and ac- 
quisition of marketing information. 

20 [0013] Referring to Figure 1, the probes shown are 
part of the distributed monitoring system, and are pas- 
sive link monitoring devices (using techniques similar to 
those in existing protocol analysers for example). The 
distributed monitoring system is constructed from the 

25 probes and standard computer and communications 
components, with special -purpose software which pro- 
vides the applications described above. A principal func- 
tion of this software is to correlate data from different 
probes to provide a record or real-time trace of calls, 

30 transactions and other services as they occur on the net- 
work. The Hewlett-Packard acceSS7 system is an ex- 
ample of a distributed passive monitoring system which 
could be used to implement parts of the system de- 
scribed above. 

35 [0014] A Data Management Infrastructure (DMI) col- 
lects the data from the probes and processes the data 
to produce service detail records. The DMI may consist 
of software running on one or more computers, and the 
processing of the data and its storage may be distributed 

40 across these computers. The service detail record gen- 
eration process may be split between the probes and 
the DMI. The probes may generate partial service detail 
records by correlating all the information available on 
that probe about a particular session, and forwarding 

45 those partial records to the DMI. The DMI is then re- 
sponsible for correlation of partial service detail records 
from different probes to form the final service detail 
records. Alternatively the probes can forward uncorre- 
cted data to the DMI, and the DMI is then responsible 

so for generating the complete service detail records. In 
both cases the DMI is also responsible for the storage 
of the service detail records and for providing interfaces 
for application programs to analyse the service detail 
records. This aspect of the DMI may be implemented 

ss using data warehousing technology. 

[0015] An example of a monitoring system architec- 
ture is given in Figure 2. This shows probes monitoring 
the PDN, SS7 network and the ISDN. The SS7 probes 
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could be for example Irom .he Hewlett-Packard 
aCC eSS7system. The ISDN primary rate access probes 
could tor example be constructed using the same lech- 
n" es as ,n existing protocol analysers -a. . «J 
Hewlett-Packard 37900D Signalling Test Set). The PDN 
probed could be constructed from Hew.ett-Packard 
4986/7 or J3457/8 LanProbes for example. 
f0016l The distributed monitoring system is arranged 
o correlate rea.-.ime data from any combiner j of 
hese probes This includes, for example. s.gnalLng data 
om X SS7 links, signaling from the ISDN £fl. 
the D-channel for narrowband ISDN), the signalling data 
o the multimedia service from the PON, and jmuj- 
media stream data (e.g. data indicating packet loss, la 
*ncy or jitter). It may also include the capture of the en- 
tire multimedia stream for applications like wire tapping 

Swith reference to the H.323 recommendatm us- 
inq IP as the PDN, and optionally connected to one or 
2e SCNs using narrowband ISDN and/or SS7 signal- 
ing with trunk connections. However, it should b e u n- 
derstood that this terminology is tobe taken as including 
wXs scope analogous functionality, whether or no 
Ly are customarily identified by the terms used in 
these standard recommendations. 



AUTO-DISCOVERY PROCESS 



[00181 The PDN is continuously mon.tored for pack- 
ets that provide configuration information on H.323 ena- 
tol and gatekeepers. These packets may bjoj- 
Led to create and maintain a database the network 
discovery database) which gives conf.gurat.on .nforma- 
Son ^dressing informal and refctionships ^between 
he endpoints and gatekeepers. The network discove^ 
database may also take data from additional sources to 
P^ment or verify the captured 

er sources should be used to generate an alarm to the 
net^rk operator indicating a possible network xonfigu- 
Z£ problem. The details of the data captured are de- 
scribed in the following paragraphs. Hhulhp 
TO0191 A type of transaction which .s tracked by the 
Ering ystem is the gatekeeper discovery process. 
?£ susedbyanendpointtoautomaticalVfndagate- 
leeper wLh wi.l provide service to it. The monitonng 
S uses the data captured from the sequence o. 

i.y endpoints and gatekeepers and to u.kl a data- 
base of the relationships between endpo.nts and gate 
keepers The database stores information derrved from 
me iptured data which identtfies the endpomt and 
leST™. includes the network addresses and 
^ numbers. The monitoring system — 
Lously for endpoint discovery attempts to ma^ir 
accurate database of the network configurator This 
monSg process is described in more detail bek>w 



Process with its gatekeeper. ' us process may be re- 
puted periodica^ if the registrar has a finite lifetime, 
s ^ monitoring system monitors the network contru- 
ou N Tor packets involved .n the registrar process 
The monLing system captures the relevant packets 
ad uses the data relating to the endpoint and gaW 
e to update and add information to the da abase. Th. 
,o wpically.ncludesanytransportaddressesdransporiad- 
dress "(Network address. Transport layer Serv.ce Ac- 
cess Pont (TSAP) or port number)), any alias address- 
es and any other addressing or configurat.on .forma- 
tion associated with the endpoint or gatekeeper 
,5 0021 Endpoints may also request from a gatekeeper 
Sn information for an endpoint for which it has he 
Sas The monitoring system will continuously monitor 

orocess and capture data Irom the relevant packets. 
20 ™ data can be' used to update or add "ton to 
me network discovery database that ident.f.es the rela- 
tonship between aliases, transport addresses ^nd any 
omer addressing or configuration inforrnat.cn. This may 
° c,ude information whfch identifies how to connect to a 
^ cpm /p n F 164 addresses). More 
25 destination on the SCN (e.g. c. ° 

2?of monitoring of the registration process are g.v- 
en below with reference to Figures 9 to 1 3. 
100221 Access tokens may be used to enable an end- 
noint to hide its transport address from the endpo.nt to 

system wi.l continuously monitor the 
oackets that are used in the process of d.stnbut.ng ac 
£ tokens to endpoints. The captured data ,s useo to 
add tfo uiate information in the network database 
ss Seeing thVassociation between an access token and 
an endpoint. 



GENERATION OF SERVICE RECORDS 



40 [0023] This section lists the types of fields in semce 
Ss and describes how the distributed monrtonng 

for example. In the case where only the PDN s be ng 
mo nS these service records include data from the 

keepers terminals and multi-pomt controllers^ and data 
She multimedia streams control!* by th.^ 

£££S any'address or configura„on in.ormat.on 
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which is not available directly from the packets involved 
in the call. 

[0024] Figure 3 shows an example of the sequence 
of packets which may be captured at different levels in 
the overall stack of protocols (such as Q.931, H.245 and 
an unreliable datagram protocol - UDP) to provide a 
service detail record. Figure 4 illustrates how the infor- 
mation from these different parts of the overall transac- 
tion can be used to contribute to different respective 
parts of a service detail record. 

1. Calling Party Information. 

[0025] This includes any information which can be de- 
rived about the calling party from the signalling data 
flowing on the PDN, and is therefore available to the link 
monitoring probes. Typical information includes: calling 
party number: any ISDN sub-addressing information: 
calling party name: network addresses; TSAP or port 
numbers: alias addresses: and any numbers or ad- 
dresses related to billing. This information can be de- 
rived from the sequence of messages used to setup a 
call. In the H.323 recommendation, this can be achieved 
by extracting the relevant fields from the Q.931 messag- 
es used in setting up the call (set-up, call proceeding, 
alerting, connect for example). In the cases where one 
or more gatekeepers are involved the admission signal- 
ling (H.225 ARQ and ACF messages for example) be- 
tween gatekeeper and endpoint is captured to identify 
the logical channel for call signalling. The logical chan- 
nel is typically identified using the transport address. 
[0026] Additional information may be derived from call 
setup messages on the ISDN D channels of an intercon- 
nected SCN, at either the originating or terminating end 
or both; and/or from call setup messages on any of the 
SS7 links of the SCN. Additional information may also 
be derived from any intelligent network service messag- 
es that flow over the SS7 links as part of the specific 
service usage. 

2. Called Party Information. 

[0027] As for calling party information, but replace 
calling party by called party. 

3. Information on each party in a conference. 

[0028] The equivalent data to the calling party infor- 
mation for each party in a conference, with additional 
information on the conference objective (join confer- 
ence, create conference or invite for example) and a 
means to identify the conference (Conference ID for ex- 
ample). 

4. Network Routing and Logical Channel Information. 

[0029] This may include any information on the net- 
work resources which were used to. provide this specific 



service usage. The following are examples of data 
which might be provided: 

logical channels associated with the call and their 
5 identifiers, 

the requested media, codecs (coder/decoders). 

service quality and bandwidth for each channel. 

the negotiated media, codecs, service quality and 

bandwidth for each channel. 
io - any other performance or configuration data on the 

channels which are requested or established during 

the call or conference. 

Each of these uses is time-stamped, and the sequence 

is and nature of the use indicated. These data can be ob- 
tained in a similar way as was described for item 1 above 
from the capture of packets carrying signalling informa- 
tion. More specifically the logical channels can be iden- 
tified by using the fields within an OpenLogicalChannel 

20 structure within certain messages defined in H.323 and 
associated recommendations. Subsequent messages 
which control the logical channels are also monitored 
and any changes in channel configuration can be time 
stamped and added to the service record. 

25 [0030] A important additional set of information is the 
measured quality of service and bandwidth usage on 
each of the logical channels set-up as part of the call. 
This will typically include packet loss rates, latency and 
jitter measurements which are made over selected in- 

30 tervals by capturing packets from the logical channels 
and extracting the relevant fields. 

5. Supplementary Services Information. 

35 [0031] This may include any information on supple- 
mentary services used for this specific service usage. 
The following are some examples of the data which may 
be provided: 

40 - call forwarding indication and address information; 
interactive voice response information on the use 
of intelligent peripherals: 
800 number services: 

any custom services that may be invoked during the 
45 call or conference. 

This information includes time-stamps, duration and the 
nature of the use. These data can be obtained in a sim- 
ilar way as was described for item 1 above. 

so 

6. Service Status and Termination Information. 

[0032] This may include time-stamped information on 
the initiation of the service, time-stamped information on 
ss any status changes occurring during service and time- 
stamped information on the termination of the service. 
The termination information should include the reasons 
for termination. 
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[0033] These data can be obtained in a similar way 
as was described for item 1 above. In particular, the H. 
245 endSesstonCommand message and the Q.931 call 
termination messages, the call clearing messages on 
the SS7 links and the ISDN D channels can provide de- 
tails on the reasons for call termination. 

7. Additional Service Quality Information. 

[0034] The service quality information provided is de- 
pendent on the service indicated in the service type field. 
The following gives some examples of what can be pro- 
vided for specific services. 

[0035] Voice quality is mainly indicated by the bit error 
rate, jitter and delay. These parameters can be meas- 
ured using a passive monitoring system and monitoring 
at two points in the network. Signalling information can 
be used to identify the logical channels on the PON. the 
ISDN B channels or the time slots on SCN trunks, that 
are carrying the voice signals. The bit streams from each 
of the channels or trunk time slots identified can be com- 
pared to derive the delay, jitter and bit error rate caused 
by the intermediate networks. 

8. Service Usage Information. 

[0036] The type of usage data provided by the distrib- 
uted monitoring system depends on the specific service. 
Some examples follow. 

[0037] Voice, video and fax services require call du- 
ration and used bandwidth. 

[0038] The data oriented services require data such 
as total bits, frames and packets in each direction. This 
may be provided for regular time intervals for the dura- 
tion of the service. It may also be broken down into a 
traffic matrix, where the data protocol has additional ad- 
dressing information (such as IP addresses). The data 
are obtained in a similar way as is described for item 1 
above. 

9. Security Information. 

[0039] A particular instance of service usage may be 
an attempt to obtain unauthorised access to resources. 
The service record includes information which may in- 
dicate this type of behaviour. This may include informa- 
tion about the duration of call, the way the call was ter- 
minated and details of the service used. 
[0040] An example would be where there are repeat- 
ed failed attempts to gain access to different resources. 

REAL-TIME UPDATES ON SERVICE USE 

[0041] The data that populates the service records 
described in the previous section can be collected in re- 
al-time from the monitoring probes. These data can be 
provided in real-time on remotely connected computers, 
as they become available. A user of the distributed mon- 



itoring system can apply filtering criteria on any of the 
information described in the previous section, to select 
those instances of service use for which real-time up- 
dates are required. 

WIRE-TAP CAPABILITY 

[0042] Any of the data extracted from the signalling 
messages can be used to match criteria set by the user 
of the monitoring system and trigger some or all of the 
logical channels to be captured in their entirety. This 
technique can be used to provide a wire-tap capability, 
which would allow real-time copies of the media streams 
to be routed through the monitoring system to a third 
party or stored for analysis. The filtering could also be 
on characteristics in the media stream (for example, a 
specific spoken word in an audio stream) which, if 
matched, would trigger the capture of all the service 
record information from the signalling messages, as de- 
scribed earlier. 

APPLICATIONS 

[0043] The following applications can be implement- 
ed using the data from the service records described 
above or the real-time service updates. Data from other 
sources may be used to enhance the effectiveness of 
these applications. 



30 



A. Quality of Service and Service Level Agreements. 

[0044] The service records described above can be 
used to provide service quality information on selected 
customer's service. This can be used to track conform- 
35 ance to service level agreements, and be provided to 
the customer as an additional service. It can be provided 
as periodic reports, or in real-time using the real-time 
updates described above. 

40 B. Surveillance and Troubleshooting for Network 
Operations. 

[0045] The service records and real-time updates can 
be used to identify service or network faults. The infor- 
mation can also be used to troubleshoot the faults. 



45 



50 



55 



C. Fraud Detection. 

[0046] The service records and real-time updates can 
be used to identity potential fraudulent use of the net- 
work or service. Indications may include excessive use 
of high value services, unusual call termination behav- 
iour and repeated failures to gain access to a service^ 
The distributed monitoring system may be used to track 
the service usage of potential high-risk users in real- 
time. 
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D. Security and Hacking Detection 

[0047] Potential security threats can be identified by 
repeated failures to gain access to a service. They also 
may be indicated by successful access to sensitive serv- 
ices, such as maintenance ports on customer premises 
equipment (CPE). This type of data is available from the 
service records and the real-time updates. 

E. Billing Data 

[0048] The service records can be used as a basis for 
billing which is dependent on any of the fields in the serv- 
ice record. This allows, for example, billing to be based 
on the actual service quality delivered. It also enables 
billing to reflect the nature and generation of the usage 
of resources on the network, such as intelligent periph- 
erals and databases. The billing data could be made 
available in real-time. 

F. Customer Accounting Data 

[0049] The detailed service usage information in the 
service records can be provided to customers for use in 
their internal accounting. This includes the traffic matrix 
information for packet and frame based protocols, which 
the system derives from the B and D ISDN channels. 

G. Customer and Telecom Operator Network Planning 

[0050] The service records can provide detailed infor- 
mation on the use of network resources which can be 
provided to network planning departments within the op- 
erator and the customer. 

H. Wire-tap 

[0051] The wire-tap capability described above can 
be used to provide wire tap services to authorized third 
parties, and potentially as a trouble shooting tool. 

MONITORING OF H.323 GATEKEEPER DISCOVERY 
TRANSACTIONS 

[0052] As noted above, the gatekeeper discovery 
process is the process an endpoint uses to determine 
which H.323 gatekeeper to register with. The process 
can be performed manually or automatically. Manual 
discovery relies on information provided independently 
to the endpoint, and analysis of the endpoint registration 
procedure in this case can be used to identify inconsist- 
encies in the available information. 
[0053] The discovery process starts when an end- 
point multicasts a Gatekeeper Request message (GRQ) 
to a predetermined address (Discovery Multicast Ad- 
dress). On receipt of such a message a gatekeeper can 
either accept (Gatekeeper Confirmation message - 
GCF) or reject (Gatekeeper Reject message - GRJ) the 



request. 

[0054] If several gatekeepers responds positively with 
GCF messages to the GRQ message, the endpoint is - 
free to choose among them arbitrarily. In this case, anal- 

5 ysis of the choice of gatekeeper can usefully reveal if a 
suitable choice was made, or it can be used to verify 
assignment policies set by system managers. Analysis 
of the list of alternative gatekeepers is also worthwhile 
since it can provide information about network redun- 

10 dancy. 

[0055] Rejection messages and no-answers to GRQ 
messages are valuable since they enable verification of 
assignment policies as well as investigation of problems 
related to multicasting. 
is [0056] Monitoring of the gatekeeper auto-discovery 
procedure is in this embodiment split into two process- 
es: 

Dispatcher process (Figure 5); and 
20 - SigProcessing process (Figure 6). 

[0057] Referring to Figure 5, the Dispatcher process 
collects all the GRQ, GCF and GRJ signalling messages 
detected by the link monitoring probes and determines 
25 the endpoint to which each refers. Then, as illustrated 
in Figure 7. the messages are dispatched to an appro- 
priate SigProcessing finite state machine (FSM) proc- 
ess which coordinates assembly of the data necessary 
to assess the gatekeeper auto-discovery procedure in 
30 relation to a specific endpoint. There need be only a sin- 
gle instance of the Dispatcher process, but several Sig- 
Processing processes can be active at the same time. 
[0058] Referring to the state definition language 
(SDL) chart in Figure 6, the SigProcessing process con- 
35 sists of an FSM which keeps track of the evolution of the 
gatekeeper auto-discovery process for a specific end- 
point. For the sake of clarity and simplicity, the chart has 
been designed with the assumption that the monitoring 
system is installed before endpoints start the gatekeep- 
40 er discovery process. In practice some endpoints might 
already be in the middle of the gatekeeper discovery 
process when the monitoring system is first installed. In 
this case a GCF or GRJ message is the first to be re- 
ceived in respect of such an endpoint, and the behaviour 
-*5 of the FSM shown in Figure 6 may be determined at the 
discretion of the system operator: incomplete informa- 
tion may be collected or, alternatively, the signalling in- 
formation involved may be discarded. 
[0059] In relation to an endpoint. the measurements 
so that can be collected and used to assess the overall 
gatekeeper auto-discovery process include: 

list of available gatekeepers (derived from GCF 
messages time-stamped and ordered); 
ss - list of gatekeepers that rejected the GRQ request 
(derived from GRJ messages time-stamped and or- 
dered); 

list of alternative gatekeepers: 
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- alarms (no answers to GRQ messages; GRQ re- 
transmissions too quick or too numerous): 

- warnings (RIP messages, i.e. gatekeepers too slow 
to answer). 

The 1 st GRQ and the GCF or GRJ can be time-stamped 
and statistics about response times can be derived. 
[0060] Similar statistics can be also obtained for dis- 
covery process performance from the point of view of 
gatekeepers. 

[0061] The case of endpoints that do not receive any 
answer to their GRQs can be worthy of study Two caus- 
es can be identified for this behaviour: GRQs may be 
sent to a multicast address different from the predeter- 
mined Discovery Multicast Address, revealing mis-con- 
figuration at the endpoint: or. as shown in Figure 8, there 
may be configuration problems within a router causing 
the router to fail to forward multicast requests from one 
sub-net to another Clearly there is also the possibility 
of network disruption that occurred at the time an end- 
point initiated the gatekeeper discovery procedure. For 
this reason it is important to keep a record of timing in- 
formation since it allows later correlation with other net- 
work events. 

[0062] The signalling messages involved in the gate- 
keeper discovery procedure and, in particular, the fields 
carrying key data for monitoring this procedure, are 
summarized below. This summary focuses on the es- 
sential fields, though more data can be extracted if de- 
sired from the signalling messages in order to provide 
more complete information about the overall gatekeeper 
discovery process. 

natfikfie per Request (GRQ) 
[0063] 

- reqSeqNum. This allows correlation with subse- 
quent signalling (GCF and GRJ messages) originat- 
ed in response to this request. 

- rasAddress. Transport address of the endpoint 
(Registration, Admission and Status - RAS - chan- 
nel). 

- endpointType. This identifies the type of endpoint 
(useful for consistency checks). 

- gatekeeperldentifier. This should be empty. Other- 
wise, it contains the identifier of the gatekeeper the 
endpoint is interested in registering with. 

fiatekeeoer Confirmation (GCF) 

[0064] 



w 
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reqSeqNum. Must be the same as in the corre- 
sponding GRQ message, 
gatekeeperldentifier This identifies the gatekeeper 
that is sending the GCF. 

rasAddress. Transport address used by the gate- 



keeper for registration and status messages. 

- alternateGatekeeper. Prioritised sequence of alter- . 
native gatekeepers and related RAS addresses. 

r.atAkfie per Reject (GRJ) 

[0065] 

- reqSeqNum. Must be the same as in the corre- 
sponding GRQ message. 

- gatekeeperldentifier. This identifies the gatekeeper 
that is sending the GRJ. 

- rejectReason. Cause code related to this rejection. 

- alternateGatekeeper. Prioritised sequence of alter- 
native gatekeepers and related RAS addresses. 
altGKisPermanent. This indicates if future RAS 
messages should be redirected to the alternative 
gatekeepers or not. 

20 MONITORING OF ENDPOINT REGISTRATION 

[0066] The endpoint registration procedure is comple- 
mentary to the gatekeeper discovery procedure, and en- 
ables an endpoint to join a -zone" managed by a chosen 
2S gatekeeper and inform the gatekeeper of Ms Transport 
Address and Alias addresses. Monitoring of this proce- 
dure enables the zone managed by one gatekeeper to 
be independently determined. It also allows correlation 
of the information gathered during monitoring of the 
30 gatekeeper discovery procedure in order to assess the 
choice of specific gatekeeper by an endpoint. 
[0067] Registration is mandatory and must be done 
before any call is attempted. Furthermore, it may occur 
periodically according to the gatekeeper's policy. It 
35 might happen that the frequency of the registration proc- 
ess is very low and that therefore signalling related to 
the registration process is rarely captured. As an alter- 
native monitoring of the admission procedure (e.g. ac- 
cording to recommendation H.225) can be used to cre- 
40 ate similar information to that gathered through monitor- 
ing of the registration process. 
[0068] The registration process involves only three 
signalling messages: usually it follows the gatekeeper 
discovery process. An endpoint sends a Registration 
45 Request message (RRQ) to a gatekeeper, using the 
gatekeeper's RAS address, which is known from the 
previous gatekeeper discovery process. On receipt of 
such a message the gatekeeper can either accept or 
reiect the request and replies with a Registration Con- 
so firr-.^on (RCF) or Registration Reject (RRJ) message, 
rec; -otively. Reasons for rejection of the registration 
can delude ambiguous registrations and security is- 

sues. . 
[0069] The registration process can be periodically re- 
55 peated since each registration may have a finite life. 
Moreover updates in an endpoint's Transport Address- 
es and/or Alias addresses are notified through new reg- 
istrations. 
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[0070] Closely related to the registration process is 
the unregistration process, by which and endpomt and 
a gatekeeper cancel the relationship which exists be- 
tween them. Either an endpoint or a gatekeeper can in- 
itiate it. It also consists of three messages. The Unreg- 
ister Request (URG) message triggers the procedure. If 
initiated by a gatekeeper the endpoint has to acknowl- 
edge it by replying with an Unregister Confirmation 
(UCF) message. If initiated by an endpoint the gate- 
keeper might reply with an Unregister Reject message 
(URJ). This might be due to the fact that the endpoint 
was not in fact previously registered with this gatekeep- 
er. The unregistration procedure may or may not be in- 
voked before a re-registration. 
[0071] A gatekeeper must keep a one-to-one map- 
ping between Transport and Alias addresses. Changes 
of both Transport and Alias addresses at once can occur 
and they should be preceded by use of the unregistra- 
tion procedure. 

[0072] Monitoring of the registration procedure is val- 
uable for several reasons. It can provide information 
needed to define zones and provide a mapping between 
Transport Addresses and Aliases. Furthermore, securi- 
ty policies can be monitored and verified and, eventual- 
ly, fraud or fraud attempts discovered. Gatekeeper load 
balance can also be usefully analysed. Finally, mapping 
of the endpoints that belong to a zone in conjunction with 
depiction of the physical representation of the network 
topology (e.g. derived using auto-discovery facilities in 
the Hewlett-Packard OpenView network management 
tool) can be extremely useful to identify network prob- 
lems such as connectivity bottlenecks or unsuitable 
gatekeeper choices. 

[0073] As mentioned earlier, the admission procedure 
can be used similarly to the registration procedure to 
generate data about the zone discovery. In this case, 
algorithms similar to those described herein can be used 
by replacing RRQ with ARQ. RCF with ACF and RRJ 
with ARJ, respectively. 

[0074] Processing of the registration and unregistra- 
tion signalling is split into two. A first Dispatcher process 
(shown in Figure 9) recognises if any of the registration 
or unregistration messages that are captured refers to 
any endpoint already registered or in the process of do- 
ing so. As illustrated by reference again to Figure 7, the 
Dispatcher process also dispatches the signalling mes- 
sage to one of two SigProcessing processes which ex- 
tract the data necessary for zone discovery. SDL charts 
for these two processes are shown in Figure 10 (regis- 
tration) and Figure 11 (unregistration), respectively. 
[0075] The measurements that can be collected in 
this way and used to generate data about zones include: 

. endpoint < — > gatekeeper relationship (dynamic re- 
lationship): 

- Transport Address < — > Alias Address correspond- 
ence (dynamic relationship); 
gatekeeper load balance: 



alarms (no answers to request messages); 
warnings (RIP messages ; i.e. gatekeepers too slow 
to answer): 

mapping of a zone over the physical network topol- 
5 ogy: 

assessment of the choice by endpoints of the gate- 
keeper to register with: 

analysis of rejections of registration and unregistra- 
tion attempts. 

w 

The endpoint-gatekeeper relationship is a temporal re- 
lationship which has a related start and end time. Simi- 
larly, the identification of endpoints through Alias and 
Transport Addresses is dynamic and it must be associ- 
is ated with timestamps. Consistency checks should pref- 
erably be carried out to verify that a unique mapping ex- 
ists between an Alias Address and the related Transport 
Address. 

[0076] It is possible to highlight cases of endpoints 
20 that do not receive any answer to RRQ or URG mes- 
sages. This might be due, for example, to the use of an 
incorrect gatekeeper RAS address. The information 
gathered about the registration procedure can be used 
to assess the choice of gatekeeper with which endpoints 
2S register and, ultimately, to determine abnormal configu- 
rations. 

[0077] Moreover, it is useful to map zones relative to 
physical network topologies. For example, Figure 12 
shows two sub-nets, each with a gatekeeper and sev- 

30 eral endpoints. More specifically, two endpoints in the 
sub-net A are registered with a gatekeeper GK B that is 
associated with another sub-net, sub-net B. This may 
be a desirable behaviour justified by gatekeeper load 
balancing policies. However, it might also be anomalous 

35 behaviour. 

[0078] With regard to gatekeeper load balance, Fig- 
ure 1 3 shows schematically the traffic between the end- 
points and the gatekeepers on the same sub-net. Clear- 
ly load imbalance exists between the two gatekeepers. 

40 As in the previous case, this may be a desirable behav- 
iour. But it might also reveal the existence of a situation 
that does not match, the desired policy put in place by 
the system administrator. 

[0079] Rejection messages, such as RRJ or URJ, can 
45 be useful to highlight either configuration or security re- 
lated problems, e.g. fraud attempts. 
[0080] The signalling messages involved in the regis- 
tration and unregistration procedure and, in particular, 
the fields that carry the key data for the monitoring of 
so these procedures, are summarized below: 

Registration Request fRRQ) 

[0081] 

55 

requestSeqNum. Monotonically increasing number 
unique to the sender. 
- discoveryComplete. Set to TRUE if the registration 
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iollows the gatekeeper discovery process. It could 
happen that when a registration ages, the gate- 
keeper discovery has to be invoked before attempt- 
ing a new registration. This is one possible reason 
for rejecting an RRQ or ARQ. 
callSignalAddress. Call signalling address lor the 
endpoint. 

rasAddress. Transport address of the endpoint 
(RAS channel). 

- terminalType. This identifies the type of endpoint 
(useful for consistency checks). 

- terminalAlias. This should be empty. Otherwise, it 
contains a list of Aliases to identify the endpoint. 

- Gatekeeperldentifier. The gatekeeper with which 
the terminal wishes to register. 

- alternateEndpoints. A sequence of endpoint alter- 
natives for CallSignallingAddress, rasAddress, ter- 
minalType, or terminalAlias. 

Registration Confirmation (RCF) 
{0082] 

requestSeqNum. Same value as for the RRQ. 

- callSignalAddress. Transport Addresses for H. 
255.0 signalling. 

- terminalAlias. A list of Alias Addresses assigned by 
the gatekeeper by which other terminals identify the 
endpoint. 

- Gatekeeperldentifier. The gatekeeper that has ac- 
cepted the endpoint registration. 

- timeToLive. Duration of the validity of the registra- 
tion. 

- preGrantedARQ. Special pre-granted permission 
to make phone calls. 

Registration Reject (RRJ) 



endpoint. 

- reason. Reason for the unregistration initiated by 
the gatekeeper. 

5 Unregistration Confirmation (UCF) 
[0085] 

- requestSeqNum. Same value as for the URQ. 
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Unregistration Reject (URJ) 
[0086] 



[0083] 

- requestSeqNum. Same value as for the RRQ. 

- rejectReason. The reason for the rejection of the 
registration. 

- Gatekeeperldentifier. The gatekeeper that has re- 
jected the endpoint registration. 

- altemateGatekeeper. Sequence of prioritised alter- 
native gatekeepers with, which to retry requests. 

- altGKisPermanent. True or False. Indicates if all 
subsequent messages are to be redirected to the 
alternative gatekeepers. 

Unregistration Request (URQ) 



[0084] 



requestSeqNum. Monotonically increasing number 
unique to the sender. 

callSignalAddress. Call signalling address for the 



is - requestSeqNum. Same value as for the URQ. 

- rejectReason. The reason for the rejection of the 
unregistration. 

- altemateGatekeeper. Sequence of prioritised alter- 
native gatekeepers with which to retry requests. 

20 - altGKisPermanent. True or False. Indicates if all 
subsequent messages are to be redirected to the 
alternative gatekeepers. 

EXAMPLE 1 - Two Endpoint© Communicating 
25 Directly without a Gatekeeper 

[0087] in this first example it is assumed that: 

- the underlying network is an IP network, TCP. is 
30 used to provide reliable connections and UDP is 

used to provide unreliable connections; 

- the two endpoints communicate directly without the 
use of a gatekeeper - this simplifies the process be- 
cause the Call Signalling Channel uses a "well- 

35 known" TSAP identifier (specified in recommenda- 
tion H.225); the case where the Call Signalling 
Channel is identified through an interaction with a 
gatekeeper is described in Example 2 below; 
. there are only two endpoints, which initiate one or 
40 more audio or video connections using Real Time 
Protocol (RTP); 

- the call is not modified during the session, for ex- 
ample by adding new participants or requesting 
changes in bandwidth; 

45 - the Call Signalling Channel remains open for the 
duration of the session, and a RELEASE COM- 
PLETE message is used to terminate the session. 

[0088] The finite state machine processes required to 
so monitor this type of session are as follows: 

1 Call Signalling Channel FSM (see Figure 14) 

[0089] This monitors all links continuously looking for 
ss a reliable-connection setup (for example, the SYN of a 
TCP connection) using the well-known TSAP identifier 
for the Call Signalling Channel. In response to a Call 
Signalling Channel being established, this process ini- 
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tiates a new Call Signalling Message FSM (CSM-FSM 
- see item 2 below) to monitor the Channel and passes 
to it the transport addresses of the two endpoints. 

2. Call Signalling Message FSM (see Figure 15) 

[0090] This is initiated to monitor a specific Call Sig- 
nalling Channel, and is terminated when the reliable 
connection is terminated tor that Channel (for example, 
by the FYN ol the TCP connection). It continuously mon- 
itors the Channel for signalling messages. A SETUP 
message indicates the start of a new call, and causes 
the process to create a new service detail record (SDR) 
for the call. The call identifier is used to uniquely identify 
the service detail record for the duration of the call, and 
to identify subsequent call signalling messages. The 
service detail record is populated with a time stamp, and 
any useful fields from the SETUP message. 
[0091] The CONNECT message sent from the called 
endpoint normally carries the transport addresses to be 
used for the H.245 Control Channel. In response to this 
message an H.245 Control Channel FSM (HCC-FSM - 
see item 3 below) is started, to monitor the H.245 sig- 
nalling for the session. The service detail record is pop- 
ulated with an additional time stamp if required, and any 
of the useful fields from the CONNECT message. 
[0092] A RELEASE COMPLETE message indicates 
the termination of the session. The service detail record 
is updated with any relevant data and time stamps, and 
then closed. The H.245 Control Channel FSM monitor- 
ing the H.245 signalling is terminated. However, moni- 
toring for subsequent signalling messages is continued 
in order to capture further calls between the two end- 
points. 

[0093] The main paths in this FSM are shown in Fig- 
ure 1 5: however in the interests of clarity error conditions 
have been omitted. The capture of other signalling mes- 
sages, particularly those involved in modifying calls, 
could also be captured and used to update the service 
detail record with additional information and time 
stamps. It may also be required to initiate further FSMs 
to monitor other aspects of the call. 

3. H.245 Control Channel FSM (see Figure 16) 

[0094] This is initiated from the Call Signalling Mes- 
sage FSM and monitors all messages on the H.245 
Control Channel for the duration of the call. The FSM is 
terminated by the detection of an endSessionCommand 
message on the H.245 Control Channel. Logical chan- 
nels are opened and closed using the openLogicai- 
Channel and closeLogicalChannel messages. The FSM 
detects the opening of a Channel, extracts the relevant 
data and initiates two new FSMs to monitor the forward 
and reverse Real Time Control Protocol (RTCP) con- 
nections (RS-FSMs - see item 4 below). A logical Chan- 
nel is uniquely identified by the Logical Channel Number 
(LCN). This is used to identify the RS-FSMs to be ter- 



minated when the closeLogicalChannel messages are 
received. 

[0095] The main process paths are indicated in Figure - 
16: however there are many more messages on the 
5 Control Channel which could be captured to provide ad- 
ditional information in the service detail record. 

4. RTCP Session FSM 

10 [0096] The RTCP connection provides detailed infor- 
mation on the performance of the RTP connection that 
it controls. This can be captured as required to provide 
quality of service information in the service detail record. 
The RTP stream itself may be monitored at multiple 

'5 points in its path to make quality of service measure- 
ments which can be added to the service detail record. 

EXAMPLE 2 -Endpoints Communicating via a 
Gatekeeper 

20 

[0097] When a gatekeeper is involved the Call Signal- 
ling Channel may no longer be carried on the well- 
known Transport Address: instead a dynamic TSAP 
identifier which the endpoint obtains from the gatekeep- 
25 er may be used. The FSM for this situation is shown in 
Figure 17. This process uses the information about 
gatekeepers and endpoints acquired during the gate- 
keeper discovery process. The RAS Channel between 
all gatekeepers and endpoints is continuously moni- 
■30 tored for control messages. An Admission Request 
(ARQ) followed by an Admission Confirmation (ACF) 
means that the endpoint has requested to setup a call 
and has been allowed to do so by the gatekeeper. The 
Transport Address which will be used for the Call Sig- 

3$ nailing Channel can be obtained from the Admission 
Confirmation message. A Call Signalling Message FSM 
is initiated to monitor the reliable connection for that 
Transport Address. The remainder of the processing 
proceeds in a similar manner to Example 1 . 

-*0 [0098] The example in Figure 17 shows the generic 
case of simply identifying the Call Signalling Channel. It 
is straightforward to extend this to include the creation 
of the service detail record in response to an Admission 
Request message from the endpoint to the gatekeeper. 
This enables the creation of service detail records which 
include information and time stamps taken from the call 
related messages on the RAS Channel. It also enables 
the generation of service detail records in the case 
where an Admission Reject message is received and no 

so Call Signalling Channel is ever established. 

[0099] The presence of gatekeepers may also affect 
the call clearing process. Typically a disengage request 
(DRQ) message is transferred between the endpoint 
and the gatekeeper as part of the call clearing process. 

ss [0100] The Call Reference Value (CRV). in cases 
where it is implemented by vendors, can be used 
throughout the call as a unique identifier for all the mes- 
sages. 
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ro101l The processes described above can be split in 
Lny different ways between the probes and the other 
orocesscrs in the Distributed Management Infrastruc 
ture There are established methods for choosing how 
o distribute the processing: the Hewlett-PacKard 
acceSS? architecture provides one example of how this 
may be achieved. 



Claims 



JO 



1. 



A method of generate generalised 
records for communications earned over a packet 
network, comprising the steps ot: 

. acquiring packet network service data from 
packets carrying the communications: 

. acquiring signalling data from a signaling pro- 
tocol to identify at least one of addressing, con- 
figuration, status and timing information or 
endpoints, gatekeepers and connections m- 
volved in a call; and 

. combining said packet service data and sad 
signalling data to generate serv.ee detail 
records. 

. The method of claim 1. wherein some or all of the 
data are captured by a passive mon.tor.ng system. 
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3 The method of claim 1 or claim 2, wherein packet - 

headers of the packets carrying the signalling data 
for the service. 

4. The method of any one of the P^f^T'^ 
eluding using the information identrhed from the s.g 

the media streams, and capture some or all of the 
pa^ets on the logical channels in real-t.me at one 
or more points in the network. 

5 The method of claim 4. wherein captured data are 
used to measure the quality of serv.ee actually 
achieved by each channel. 

6 The method of claim 4, wherein captured data are 

provide secret access to the med* stream 
for troubleshooting or surveillance purposes. 



generalised service detail records, 
a The method of claim B, including use of data col- 

work (e.g. SS7) or access signalling (e.g. ISDN, B 
ISDN). 

in The method of claim 8, including use of data col- 

I Sed from the switched circuit network for audio or 

video quality. 

II The method of any one of the preceding claims, in- 
I uding using the generalised service detail records 
(1 bin ? or the service, optionally taking .n.o account 
he la ti o. serv^e and usage data, andopt.ona.ly 

ceeding their agreed bandwidth constra.nts. 

12 The method of any one of the preceding claims, in- 

to detect potentially fraudulent serv.ee usage, per- 
orm nelork planning, perform marketing etu** 
p rfon. network operations 
network configuration in real-time to achieve qualrty 
oUerviceobjectives, and/or perform customer care 
functions, 

A method of discovering the network figuration 
of the endpoints, gatekeepers and their reteton 
ships for a communications serv.ee earned by a 
packet network, by using a passive mon,tor.ng sy - 
fern to capture the signalling messages .nvorved -n 
he configuration and negotiation of relat.onsh.ps, 
Addressing and resource al.ocaf.on, between end- 
points and gatekeepers. 

14 Themethodof claim 1 3, wherein the signalling mes- 
laqeTcaptured are gatekeeper request, gatekeep- 
"con— and gatekeeper reject message, 
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SO 



7 The method ot claim 6. wherein addressing ^. for- 
mation for the target user is used to 
rect signalling packets, potent.ally -n eon,unct,on 
with data from a network discovery database. 

8 The method of any one of the preceding jdairr*£ « 
cludingcorrelatingthedatafromthepaeketnet^k 

with data collected from a switched c.rcurt network 
Tsuch as a PSTN, ISDN or B-ISDN) to enhance the 



iB ThemethodofclaimU.whereindataareextract^ 
IomThecapturedsigna.lingmessagesto.dent.fyat 
ea^e of the following types of informal avart- 
S gatekeepers. ^J***^ 

spond to requests. 

1 6 The method of claim 1 3. wherein the signalling mes- 
^ captured are endpoint registrar request 
messages and associated registration conf.rmat.on 

and reject messages. 

17 The method of claim 1 6, wherein data are exacted 
from the captured signallingmessages to .dent vat. 

Sn hips between gatekeepers and endponts, cor- 
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relations between Transport Addresses and Alias 
addresses, gatekeeper load balance, endpoints re- 
ceiving no response to request messages, gate- 
keepers which are excessively slow to respond to 
requests, correlation between gatekeeper zones 5 
and physical network topology, choice by endpoints 
of gatekeepers with which to register, and rejections 
of registration requests. 

18. A method of generating generalised service detail 
records for communications carried over a packet 
network, comprising the steps of:. 

acquiring packet network service data for the 
packets carrying the communications service: 
acquiring signalling data regarding at least one 
of call control, registration, admissions, band- 
width management, call status, address trans- 
lation and intelligent network services: 
acquiring quality of service data for the service 
transmission level: and 

combining said service data, said signalling da- 
ta and said quality of service data to generate 
generalised service detail records. 

19. The method of any one of the preceding claims, 
wherein the capture of packets is performed at mul- 
tiple points in real time, and then correlated in real- 
time. 

20. The method of any one of the preceding claims, 
wherein the communications comprise real-time 
voice or audio, fax, voice-messaging, real time vid- 
eo or multimedia communications. 

21. The method of any one of the preceding claims, 
wherein the packet network is an IP. frame relay or 
ATM network. 

22. A method of monitoring a packet data sub-network *o 
or link, comprising the steps of: monitoring at a first 
location signalling messages to detect the exist- 
ence of a call: and monitoring at multiple other lo- 
cations to identify some or all packets associated 
with the call. 45 
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